Workflow for the automatic creation of armv8 and amd64 docker images #298
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem:
At present, there is no docker image for armv8/arm64/aarch64 architectures. A fairly sizable target for the genie-server are SBCs (Single Board Computers) such as Raspberry Pi/Orange Pi and others which are based on the ARM architecture as mentioned in #228. This PR addresses that.
Solution:
The following workflow file leverages Github Actions and GitHub infrastructure to (semi-)automatically build and push docker images to docker hub for both arm64 and amd64 architectures. On the client side, docker can detect and pull the image of the appropriate architecture. A build-log of a test-run of this workflow can be found here here and the respective built docker images here.
Important:
At present, this PR is a POC and is not ready to be merged as the workflow is manually triggered and pushes docker images with the :latest tag only. If this PR is positively perceived, I can adapt it to be triggered on commits where docker images are pushed with the tags :commit-hash and :latest or alternatively be triggered on new releases with tags :release_version and :latest. Alternative approaches are also welcome. A necessary input for this workflow to execute are the addition docker hub username and password as repository secrets (and optimally, a docker hub token, which can be used to update the docker hub image description using that in the github repository as accomplished here).